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(54) Identifying solutions to computer problems by expert system using contexts and 
distinguishing versions 



(57) A computer system (200/300) has a main sys- 
tem (200) to execute an application (A) In cooperation 
with a human user (1000). The auxiliary system (300) 
evaluates problems (P) in the main system (200). The 
auxiliary system (300) has a service module (31 0) to col- 
lect problem related data (D) from the main system 
(200), an acquisition module (320) to acquire knowledge 



representations (R), a knowledge module (330) to store 
knowledge representations (R), an inference module 
(340) for processing problem related data (D) with 
knowledge representations (R) to identify solutions (S) 
and for forwarding the solutions (S) through the service 
module (310) to the main system (200). The auxiliary 
system (200) distinguishes context of the problems (P) 
and distinguishes versions of the main system (200). 
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Description 

Field of Invention 

[0001] The present invention generally relates to data 
processing by computer systems, programs, and meth- 
ods. More particularly, the invention relates to evaluat- 
ing and solving problems. The computer systems are 
distinguished into main, auxiliary and service systems. 

Background 

[0002] Electronic data processing uses integrated 
and distributed computer systems with complex archi- 
tecture. Coupling different computers over networks (e. 
g., Internet) enhances functionality but adds complexity 
and increases maintenance. 

[0003] Each computer system operates in the com- 
plexity of hardware (e.g., computers and network) and 
software (e.g., operating systems, applications, data- 
bases). 

[0004] Problems are deviations from the predefined 
operation of the computer system that are caused by 
malfunction of hardware or software or by improper in- 
put by the user. To name a few examples, components 
like processors suddenly fail, applications occasionally 
provide wrong results, and users sometimes manipulate 
data. 

[0005] Problems often remain hidden from the user. 
Once detected, the user engages in problem solving. 
For example, the user reads documentation papers, ac- 
tivates help functions (e.g., predefined advices, often 
obtained via online services), looks up in databases to 
identify advices ("notes"), makes experiments, or tells 
problem symptoms to specialists (e.g., through phone 
hotline, email, Internet portal). 

[0006] A majority of users relies on passive assist- 
ance; only a minority actively solves the problem. There 
are further challenges: For example, sensitive data re- 
mains with the authorized user but is shielded from spe- 
cialists (data protection); users and specialists might in- 
troduce further errors. In any case, problem solving re- 
mains time consuming and expensive. 
[0007] Further, heterogeneous system landscapes 
have systems that differ for example, by manufacturer, 
release version, and application. Each difference in- 
creases the number of potential problems and corre- 
sponding solutions. Selecting solutions becomes criti- 
cal. 

[0008] There is a need to improve problem solving by 
mitigating disadvantages of the prior art. 

Brief Description of the Drawings 

[0009] 
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auxiliary syster?H5ccording to the present in- 
vention; 

illustrates the system of FIG. 1 with more de- 
tail; 

illustrates a service module in the auxiliary 
system with more detail; 
illustrates an acquisition module in the aux- 
iliary system with more detail; 
illustrates a knowledge module in the auxil- 
iary system with more detail; 
illustrates an inference module in the auxil- 
iary system with more detail; 
illustrates a first distributed system land- 
scape with the main and auxiliary systems 
coupled to a service system; 
illustrates a second distributed system land- 
scape with 2 main systems coupled to a 
service system; 

illustrates a simplified flowchart diagram of a 
method for operating the main, auxiliary and 
service systems; 

illustrates a simplified scenario that consid- 
ers interaction, and thereby distinguishes 
automatically problem evaluating and semi- 
automatically problem evaluating; 
illustrates a simplified scenario that consid- 
ers primary and secondary context; 
illustrates a simplified scenario that consid- 
ers the distribution of problem collecting and 
solution processing in the system land- 
scapes; 

illustrates further simplified scenarios; 
summarizes various aspects of the present 
invention by concentrating on an inference 
module; and 

illustrates a simplified block diagram of a 
computer system in general for that the 
present invention can be implemented. 



FIG. 1 illustrates a simplified block diagram of a 
computer system with a main system and an 



40 Detailed Description 



[001 0] An exemplary implementation for the invention 
uses the well-known system R/3. R/3 is commercially 
available from SAP Aktiengesellschaft Walldorf (Baden, 
Germany, "SAP"). Organizations (i.e. SAP customers) 
use enterprise resource planning applications ("ERP 
applications", or "business applications") to organize in- 
formation in a variety of fields, such as supply chain 
management (SCM), customer relationship manage- 
ment (CRM), financials, human resources (HR), enter- 
prise portals, exchanges, technology, product lifecycle 
management (PLM), supplier relationship management 
<SRM), business intelligence, business intelligence, 
mobile business, hosted solutions, small and midsize 
business, and industry solutions. ABAB/4 is the well- 
known programming language used by SAP to define 
transactions for applications. R/3 and ABAB/4 is docu- 
mented by a variety of reference books, such as: 
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Gareth M. de Bruyn, Ro^m Lyfareff, Ken Kroes: 
"Advanced ABAP Programming for SAP". Prima 
Publishing 1999. ISBN 0-7615-1798-7. 
Bernd Matzke: "Programming the SAP R/3 Sys- 
tem". Addison-Wesley, 1 997. ISBN 0-201 : 92471 -4. 
Jonathan Blain, ASAP World Consultancy: "Special 
Edition Using SAP R/3, Third Edition. Que. 1999. 
ISBN 0-7897-1821-9. 

[001 1 ] A detailed description of a computer system in 
general and a list of reference numbers are provided as 
the end of the specification. 

[0012] In short, according to the invention, a computer 
system has a main system to execute an application (A) 
in cooperation with a human user and has an auxiliary 
expert system to evaluate problems (P) in the main sys- 
tem. Optionally, the problems are solved by predefined 
instructions. 

[0013] The auxiliary system uses knowledge repre- 
sentations (R) in primary and secondary contexts. The 
auxiliary system distinguishes versions of the main sys- 
tem and - optionally - versions of the application (A). 
Knowledge representations (R) are classified into con- 
text groups. 

[0014] The present invention enables the user to ac- 
tively solve problems in the main system mostly without 
asking for advice by human specialists. Applying the in- 
vention saves time and quickly returns the main system 
back to normal operation. Applying further features ef- 
fectively escalates problem evaluation to the service 
system. Involving human specialists (often expensive) 
is only required as a last remedy. 
[0015] FIG. 1 illustrates a simplified block diagram of 
a computer system with main system 200 and auxiliary 
system 300 according to the present invention. 
[0016] Computer system 200/300 has main system 
200 to execute application A in cooperation with human 
user 1000. Auxiliary system 300 evaluates problems P 
in main system 200. Auxiliary system 300 has service 
module 31 0 to collect problem related data D from main 
system 200, acquisition module 320 to acquire knowl- 
edge representations R, knowledge module 330 to store 
knowledge representations R, inference module 340 for 
processing problem related data D with knowledge rep- 
resentations R to identify solutions S and for forwarding 
the solutions S through service module 31 0 to main sys- 
tem 200. Throughout the modules, auxiliary system con- 
siders context and versions (of main system 200 and 
application A). 

[0017] Auxiliary system 300 finds problem related da- 
ta D by evaluating the problem environment in main sys- 
tem 200: date, time, memory usage, data objects, soft- 
ware modules of application and operating system and 
the like. 

[0018] FIG. 2 illustrates main system 200 and auxilia- 
ry systems 300 with more detail. Main system 200 has 
a client/server configuration with database 210 (prefer- 
ably, relational database), application server 220 and 



439 A1 

front-end server 230. 




[0019] The following refers to an exemplary imple- 
mentation: Main system 200 and auxiliary system 300 
are implemented by an R/3 type system. System 200 
s performs an ERP application. The ERP application is 
defined by instructions that have common keywords, 
common syntax and common semantic with environ- 
ments selected from the group of: ABAB/4, Java 2 Plat- 
form Enterprise Edition (J2EE), and.NET framework. 

10 Auxiliary system 300 uses the client/server configura- 
tion (210, 220, 230) of main system 200: the modules 
of auxiliary system 300 are distributed such that service 
module 310, acquisition module 320, knowledge mod- 
ule 330, inference module 340 are arranged in parallel 

15 to application server 220 and to database 210. Front- 
end server 230 operates as user-interface both for main 
system 200 and auxiliary system 300. In other words, 
database 21 0 implements a storing function, application 
server 220 implements the application (A,cf. FIG. 1) and 

20 front-end server 230 implements presentations (e.g., 
user interface). The module distributions can be modi- 
fied. For example, knowledge module 330 can be part 
of database 210. Internet communication is used be- 
tween application server 220 and front-end server 230. 

25 Internet communication is implemented by well-known 
techniques (e.g., TCP/IP, HTML, and HTTP). 
[0020] Having introduced main system 200 and aux- 
iliary system 300 in general, the following sections de- 
scribe the modules with more detail. 

30 [0021] FIG. 3 illustrates service module 31 0, especial- 
ly its cooperation with main system 200 (dashed frame) 
in the exemplary implementation. Service module 310 
makes basis service functions of main system 200 avail- 
able for auxiliary system 300 (cf. FIG. 2). Basis service 

35 functions are: ABAP/4 workbench, administration, au- 
thorizations, batch input, data dictionary, dialog control, 
framework, graphical user interface, application pro- 
gram interface, and job. Basis services are explained in 
the above-cited reference books. Service module 310 

40 cooperates with main system 200 to obtain problem re- 
lated data D for auxiliary system 300. Service module 
31 0 cooperates with database 21 0 to test the existence 
of objects: The problem related data D comprises infor- 
mation about existence and non-existence of the ob- 

45 jects. The objects are related to application A (in server 
220). 

[0022] Service module 310 cooperates with database 
210 to obtain the content of a table entry as problem 
related data D. Service module 310 records events in 
so the operating system of main system 200 by writing to 
database 21 0. Service module 31 0 records problem re- 
lated data D obtained from data consistency check op- 
erations of main system 200 (e.g., application server 
220). Consistency checks determine consistency (non- 
55 consistency) of data in database 210, especially in the 
database tables: Entries in the table-body should be 
consistent with the entries in the table-header. For ex- 
ample, the body holds zip-code numbers below headers 
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"zip-code". Service module 3lWKtructs front-end serv- 
er 230 to provide dialogs with user 1 000. Service mod- 
ule 31 0 provides remote function call (RFC) connections 
with further auxiliary systems (with similar modules), 
such as with a service system (cf. FIG. 6). s 
[0023] Service module 31 0 monitors application serv- 
er 220 and database 210 according to instructions from 
inference module 340. 

[0024] FIG. 4 illustrates acquisition module 320forthe 
exemplary implementation. Acquisition module 320 also io 
modifies knowledge representations R. Acquisition 
module 320 interacts with knowledge engineer 1 001 , as 
illustrated, through tree 322 on a graphical user inter- 
face. Acquisition module 320 uses tree 322 to represent 
the knowledge representations R as a semantic net. En- 15 
gineer 1001 may use well-known edit or drag and drop 
techniques to manipulate the representations. 
[0025] Knowledge engineers are, for example, (a) 
software developers who are familiar with main system 
200, (b) technical writers who write documentations for 20 
customers, and (c) persons that have gathered experi- 
ence as being a user (cf. 1000 in FIG. 1). Tree 322 as- 
sists engineer 1001 to modify knowledge representa- 
tions. As in the example, tree 322 represents a rule re- 
lating to a patch type. The rule has a query step (Down- zs 
load OK?) and conditional steps. A patch is distin- 
guished by its source between Compact Disk, OSS (on- 
line service system, cf. reference books), and Internet. 
Depending on the source, different advices can be de- 
fined. Also, user 1001 is invited to modify tree 322 by 30 
inserting icons from an icon tray ("insert objects"). 
[0026] FIG. 5 illustrates knowledge module 330 for 
the exemplary implementation. Knowledge module 330 
stores knowledge representations R by classifying into 
context, for example, business transactions as part of 35 
the application A, executable programs as part of the 
application A, and hierarchy level within the application 
A. 

[0027] Optionally, knowledge module 330 uses lexi- 
con 331 to distinguish versions of main system 200 (e. 40 
g., versions "1.0" and "2.0"). Lexicon 331 defines pa- 
rameters Pa (for a particular version) and knowledge 
representations R (for all versions). The figure illustrates 
the different parameters by different hatching. Distin- 
guishing is very convenient if auxiliary system 300 45 
serves 2 or more main systems 200 that have different 
version (i.e. release or language). For example, main 
systems 200 might differ in their table definitions due to 
different release dates. Distinguishing through parame- 
ters for equal representations helps to keep the number so 
of knowledge representations at a convenient level. 
Useful is also to distinguish between different natural 
languages: For example, while a first main system com- 
municates with its users in German; a second main sys- 
tem communicates with its users in English; both mains 55 
systems are supported by a common auxiliary system 
that provides dialog texts in English or German. Knowl- 
edge module 330 makes the knowledge representa- 



laD^ror 



tions R selectively availaW^r non-available according 
to a selected context or version. 
[0028] Knowledge module 330 distinguishes context 
with primary context and secondary context, wherein 
the secondary context is referenced from the first con- 
text. The first context can refer to the second context, 
the second context can refer to the first context, or both 
contexts can refer to each other. Knowledge module 330 
selects knowledge representations R to be considered 
by inference module 340 according to the context of a 
current transaction by the application server 220. Se- 
lected context is selected by user 1000 or by a prede- 
fined rule. For example, the context is selected from: 
system and program performance, background 
processing, OCS and patches, data dictionary, printer 
problems, remote function calls and connectivity, R/3 re- 
porting, and security and administration. For example, 
the first context is defined by the application with atrans- 
action "Patch Manager". Problem P and data D are 
"Patch not found". Knowledge representations R have 
hints to find a storage location for patches (e.g., a direc- 
tory or a server). But processing does not result in a so- 
lution S. The problem remains unsolved. However, the 
link "Transport" refers from the first context to the sec- 
ond context. The second context leads to knowledge 
representations R to software installing procedures. 
Processing with these representations R leads to solu- 
tions S. 

[0029] Knowledge module 330 is adapted to receive 
regular updates of the knowledge representations R (ar- 
row symbol). The updates can originate, for example, 
from a service system (cf. FIG. 5) that acts as further 
auxiliary system. Knowledge module 330 stores knowl- 
edge representations R in database 210 with entries for 
specific problem P symptoms and corresponding solu- 
tions S. Knowledge niodule 330 stores knowledge rep- 
resentations R that point to predefined solution identifi- 
cation rules in database 210 (or in module 330 itself). 
The solution identification rules are provided in a meta 
language. The meta-language is derived from ABAP/4. 
[0030] The rules usually identify action, object, argu- 
ments and result location. An example for meta lan- 
guage is, for example, a 2-line rule for storing data. The 
first line reads as "CALL" (action), "FUNCTION" (ob- 
ject), "GET_FILE_PATH" (argument), and "FILE_PATH" 
(result location) to find a file directory (path) and to keep 
the file directory in a first variable ("FILE PATH"). The 
second line reads as "CHECK_EXIST (action), "FILE" 
(object), "< F I LE_ PATH >/rf c .trc" (argument) and "EX- 
IST" (result location) to check the existence of file "rfc. 
trc" in the directory and to write existence/absence re- 
sult into a variable ("EXIST"). 

[0031] Providing R in meta-language in convenient for 
automatically processing. Markup languages (e.g., 
XML) are also useful. It is an advantage that R can also 
be provided partially or completely in natural languages 
(e.g., English) for "processing" by a human. 
[0032] Knowledge module 330 generates a struc- 
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tured set of problem solvin^wategies, such as so- 
called "troubleshooting guides". 

[0033] These are strategies for consideration by a 
specialist or by the user. 

[0034] Knowledge module 330 generates solution s 
identification rules with computer instructions that the 
computer utilizes to automatically solve the problem. 
Preferably, knowledge module 330 distinguishes error 
classes (details below). 

[0035] Sets of semantically related solution identifica- 10 
tion rules are grouped together, such as rules to find the 
problem "inconsistency in a table", and rules to find the 
corresponding code to "automatically re-arrange the ta- 
ble" (i.e. utilizing the solution). Tables in the database 
210 are not only used to organize data for application is 
A, but also convenient for knowledge module 330 to 
stores knowledge representations R. In that case, the 
tables are provided prior to activating auxiliary system 
300. 

[0036] The following Is an example for using knowl- 20 
edge representations R, context and check lexicon: The 

knowledge representations form a set of R1 , R2, R3 

R16, R99 (consecutively numbered). Each R is de- 
fined by meta-language, such as "CHECK PRINTER 
CONNECTION" for R1 6. 25 
[0037] Context are subsets of representations for that 
relate to problem classes, such as context PRINTER 
with R5, R6 and R1 6. The check lexicon lists details for 
knowledge representations depending on versions of 
main system 200 (optionally versions of application A), so 
R1 6 for version 3.0 testing an IP connection by a stand- 
ard "PING PRT' command to the printer; for version 3.1 
calling a dedicated test function (in auxiliary system 
300); for version 4.0 instructing the printer to print a test 
page. 35 
[0038] When processing problem data D such as 
"printing not possible" for main system 300 of version 
3.0, auxiliary system 200 extract the context set PRINT- 
ER from all R, checks the lexicon for applicable details 
and applies each R in combination with the details (e. 40 
g., Ri 6 PING PRT). If a solution is still missing, the con- 
text changes, for example, to GENERAL with R1 
"CHECK POWER SUPPLY". Applying RI - this time 
without distinguishing versions - leads to a success. The 
printer was not connected to the mains power. The so- 45 
lution S is identified as a message to the user that is 
forwarded to the user (in the further context of the Eng- 
lish language, through the front-end server): "Please 
connect your printer to the 230 volts power supply." 
[0039] FIG. 6 illustrates inference module 340 in aux- so 
iliary system 300 with more detail. Inference module 340 
identifies the solutions Sfrom sets of predefined advices 
(preferably, advices of application A) by a solution iden- 
tifier. 

[0040] Inference module 340 identifies the solutions ss 
by applying the knowledge representations R (to data 
D) in a predefined orderthat is, for example, a sequential 
order (e.g., R1, R2, R3), a hierarchical order (e.g., R1, 
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R21, R21, R31, R32), aTlJnamically adaptive order in 
that the order might chance by conditional jumps or the 
like (e.g., IF THEN). 

[0041] Inference module 340 communicates ques- 
tions to user 1 000 (cf . Q1 , Q2, Q3 reservoir). Preferably, 
the questions are standard questions. Inference module 
340 consecutively numbers the questions. Inference 
module 340 composes the questions from predefined 
passages that are provided by application server 220. 
Inference module 340 analyzes the responses that user 
1 000 enters in natural language (cf. language analyzer). 
[0042] So far the exemplary implementation has been 
described with main system 200 and auxiliary system 
300 that communicate by basis functions and that are 
implemented by a single R/3 system. Distributing mod- 
ules of auxiliary system 300 to a client/server system 
configuration is convenient. The invention is however 
not limited to that. Further implementations benefit from 
the following: 

(a) Main and auxiliary systems can be distributed to 
different computer systems (e.g., different R/3 sys- 
tems; cf. FIG. 7). 

(b) A further auxiliary system (here called service 
system) can provide enhanced problem evaluation 
capacities (cf. FIG. 7). 

(c) One auxiliary system can serve 2 or more main 
systems (cf. FIG. 8). 

d) Applicable knowledge representations can be 
selected for a particular version of the main system, 
for example* by maintaining a check lexicon. 

e) A first auxiliary system starts to evaluate the 
problem by first knowledge representations and for- 
wards evaluation results to a second auxiliary sys- 
tem. The second auxiliary system then returns a 
second (enhanced) knowledge representation to 
enable the first auxiliary system to finish the evalu- 
ation. 

[0043] For convenience of explanation, the following 
uses the term "system 200/300" collectively for the com- 
bination of main system 200 with auxiliary system 300 
for main system 200 alone. In other words, auxiliary sys- 
tem 300 is not longer required in any case. 
[0044] FIG. 7 illustrates a first distributed system land- 
scape with system 200/300 coupled to a service system 
500 via a network. Service system 500 has auxiliary 
components with functions that are substantially similar 
to that of auxiliary system 300: service module 510, ac- 
quisition module 520, knowledge module 530, inference 
module 540 as well as modules for front-end communi- 
cation. The foregoing description is applicable for these 
modules as well. 

[0045] Preferably, system 500 operates independent- 
ly from any main system and does not execute an ERP 
application. Optionally but not mandatory, service sys- 
tem 500 has a client/server configuration, such as sys- 
tem 500 in an exemplary implementation being an R/3 
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type system. In comparison tWfftem 200, service sys- 
tem 500 uses knowledge representations R that are en- 
hanced in terms of volume, actuality, and complexity. If 
required, system 500 also solves problems in auxiliary 
system 300. In short, system 500 has at least the above- s 
mentioned functions of auxiliary system 300 and serves 
as the expert system for system 200/300. 
[0046] Service system 500 is conveniently installed at 
a manufacturer's site (of system 200/300) and commu- 
nicates with system 200/300 by receiving problem data 10 
(D) from system 200/300 and sending control instruc- 
tions (C) to system 200/300. Service system 500 is - op- 
tionally - operated by service engineer 1002 who helps 
to solve problems in system 200/300. Dynamic en- 
hancement is possible: control instructions C are con- 15 
veniently also used to regularly update knowledge mod- 
ule 330 with actual knowledge representations (R, cf. 
FIG. 5 updates). If system 200/300 is implemented with 
auxiliary system 300, then auxiliary system 300 acts as 
a first expert system and service system 500 act as a 20 
second expert system. Depending on the severity of the 
problem (in system 200), problems are evaluated as fol- 
lows: 

(1 ) Auxiliary system 200 solves the problem (i.e. so- 25 
lutions S are identified by system 300). 

(2) Auxiliary system 200 does not solve the problem 
but forwards a package with problem P data in com- 
bination with preliminary solutions S (i.e., P/S data, 
based on knowledge representations (R) in system 30 
200) to service system 500. Service system 500 
then solves the problem. 

(3) Auxiliary system 200 does not solve the problem 
but forwards the P/S data package to service sys- 
tem 500. System 500 uses the P/S data to return 35 
further knowledge representations. This enables 
system 200 to evaluate and solve the problem. 

(4) Service system 500 does not solve the problem 
automatically and needs to interact with service en- 
gineer 1002 (further analysis by a human techni- 40 
cian). 

[0047] FIG. 8 illustrates a second distributed system 
landscape with main systems 201 and 202 coupled to 
service system 500. The approach of FIG. 7 has been 45 
expanded by adding a further main system. Optionally, 
service system 500 is operated by a service engineer 
(cf. 1002). 

[0048] In the exemplary implementation, main system 
201 is physically implemented on a first computer; main so 
system 202 (as system 201 also in client/server config- 
uration) is implemented on a second computer, service 
system 500 is implemented on a third computer. Auxil- 
iary systems are optionally added to main systems 201 
and 202. 55 
[0049] Main system 201 is adapted to be operated by 
a first customer (e.g., a first company), service system 
500 is implemented by expertise service provider ESP 
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and main system 202 is^lfapted to be operated by a 
second customer (e.g., a second company). For exam- 
ple, ESP is the manufacturer of systems 201/500/202 
or is a consulting agency. Preferably, main systems 201 
and 201 are systems of the same type (e.g., R/3), but 
have different release versions (i.e. 201 older than 202, 
or vice versa). Different release versions are distin- 
guished by context groups, (cf. FIG. 5). Such an ar- 
rangement is convenient also for main systems that 
communicate with their users in different natural lan- 
guages. While problem identification is technically the 
same in systems 201/202, messages to users (e.g., 
notes, dialogs) can be in different natural languages. 
[0050] Some or all of the computers are located at 
physically different locations. Expertise of service sys- 
tem 500 becomes available around the globe. Service 
system 500 could simultaneously serve main systems 
201/202 in different continents around the clock. 
[0051] Having service system 500 physically separat- 
ed from main systems 201/200 has further beneficial ef- 
fects: For example, expertise (i.e. knowledge represen- 
tations R) is shielded from access by main system 
201/202; and sensitive data on main systems 201/202 
is shielded from access by service system 500. Further 
distributions of main, auxiliary and service systems are 
possible. For example, a plurality of main systems can 
be equipped with auxiliary systems that solve problems 
for their corresponding main system or forward problem 
data to service systems. 

[0052] FIG. 9 illustrates a simplified flowchart diagram 
of method 400 for operating computer system 200/300. 
Method 400 is also applicable if auxiliary system 300 is 
replaced by service system 500. 
[0053] As stated above, system 200/300 has main 
system 200 executing application A in cooperation with 
human user 1000 and has auxiliary system 300 evalu- 
ating problems P in main system 200. According to 
method 400, auxiliary system 300 performs the follow- 
ing steps: collecting 410 problem related data D from 
main system 200, acquiring 420 knowledge representa- 
tions R, storing 430 knowledge representations R, 
processing 441 problem related data D with knowledge 
representations R to identify solutions S, and forwarding 
442 the solutions S through service module 31 0 to main 
system 200. Method steps are also illustrated in FIG. 1 
by arrows COLLECT, ACQUIRE, STORE, PROCESS, 
FORWARD. 

[0054] In the exemplary implementation, step collect- 
ing 410 is performed by service module 310; step ac- 
quiring 420 is performed by acquisition module 320; 
step storing 430 is performed by knowledge module 
330; and steps processing 441 and forwarding 442 are 
executed by inference module 340. Modules 310-340 
have been explained in connection with FIGS. 1-6. 
[0055] In the exemplary implementation, steps col- 
lecting 410, acquiring 420, storing 430, processing 441 
and forwarding 442 are performed for main system 200 
that has a client/server conf iguration with database 21 0, 
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application server 220, and ff^Pind server 230. Steps 
collecting 410, acquiring 420, storing 430, processing 
441 and forwarding 442 are performed in modules 310, 
320, 330, 340 (of auxiliary system 300) that are ar- 
ranged in parallel to main system 200. s 
[0056] Steps acquiring 420 knowledge representa- 
tions R and forwarding 442 solutions S comprise to op- 
erate a user-interface in front-end server 230 of main 
system 200. Steps collecting 41 0, acquiring 420, storing 
430, processing 441 and forwarding 442 are performed io 
by basis service functions of main system 200. The fol- 
lowing is optional for step collecting 410: Service mod- 
ule 31 0 cooperates with main system 200. Service mod- 
ule 310 cooperates with database 210 to test the exist- 
ence of objects: problem-related data D informs about 15 
existence and non-existence of the objects. Service 
module 31 0 cooperates with database 21 0 to obtain the 
content of a table entry as problem related data D. Serv- 
ice module 310 records events in the operating system 
of main system 200 by writing to database 210. Service 20 
module 310 records problem related data D obtained 
from data consistency check operations of main system 
300. Service module 31 0 instructs front-end server 230 
to provide dialogs with user 1000. Service module 310 
provides remote function call RFC connections with 25 
service system 500 (operating like a remote auxiliary 
system). Service module 310 monitors application serv- 
er 220 and database 21 0 according to instructions from 
inference module 340. 

[0057] The following is optional for step acquiring 420: 30 
Acquisition module 320 modifies the knowledge repre- 
sentations R. Acquisition module 320 interacts with a ' 
knowledge engineer. Acquisition module 320 interacts 
with the knowledge engineer through tree 322 on a 
graphical user interface (cf . FIG. 4). Acquisition module 35 
320 uses tree 322 to represent knowledge representa- 
tions R as a semantic net. 

[0058] The following is optional for step storing 430: 
Knowledge module 330 classifies the knowledge repre- 
sentations R into context groups. Knowledge module 40 
330 organizes the context groups by lexicon 331 (cf. 
FIG. 5). Knowledge module 330 defines the context by 
a version of main system 200 and defines lexicon 331 
by knowledge representations for the versions. Knowl- 
edge module 330 makes the knowledge representa- 45 
tions R selectively available or non-available according 
to a selected context for subsequent step processing 
441 . Knowledge module 330 distinguishes context be- 
tween primary context and secondary context. Knowl- 
edge module 330 stores knowledge representations R so 
in database 210 with entries for specific problem P 
symptoms and corresponding solutions S. Knowledge 
module 330 stores knowledge representations R in da- 
tabase 210 with entries for predefined solutions identi- 
fication rules. Knowledge module 330 stores knowledge ss 
representations R in a plurality of tables in database 
210. 

[0059] The following is optional for step processing 
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441: Inference module 39^5erforms an action such as 
to: identify the solutions S form a set of predefined ad- 
vices of the application A, identify the solutions S by ap- 
plying knowledge representations R in a sequential or- 
der, identify the solutions S by applying knowledge rep- 
resentations R in a hierarchical order, identify the solu- 
tions S by applying knowledge representations R in a 
dynamically adaptive order, communicate questions to 
user 1 000 by composing the questions from predefined 
passages provided by application A, analyse responses 
that user 1000 enters in natural language. 
[0060] Optionally, systems 200/300 cooperate with 
service system 500 (cf. FIG. 7): While executing any of 
steps collecting 410, acquiring 420, storing 430, 
processing 441 and forwarding 442, auxiliary system 
300 conditionally forwards problem P data in combina- 
tion with solutions S to service system 500. In the alter- 
native, auxiliary system 300 forwards problem P data 
and solutions S for further analysts by a human techni- 
cian. 

Auxiliary system 300 forwards problem P data and so- 
lutions S in a format that allows analysis by an expert 
system, for example by service system 500. 
[0061] In short, executing method 400 depends on a 
variety of circumstances. FIGS. 9-10 give exemplary 
overviews for scenarios that develop dynamically and 
that adapt the particular circumstances. 
[0062] For illustration, exemplary scenarios refer to 
interaction (FIG. 10), context (FIG. 11) and distribution 
of problem collecting and solution processing (FIG. 12). 
The following description denotes queries by question 
marks. 

[0063] FIG. 10 illustrates a simplified scenario that 
considers interaction, and thereby distinguishes to au- 
tomatically evaluate the problem and to semi-automat- 
ically evaluate the problem. Interaction occurs among 
systems 200, 300 and 500 and human user 1000. 

(10) Is interaction between main system 200 and 
auxiliary system 300 (or service system 500) re- 
quired? The yes/no answer could depend on the 
performance during collecting or processing steps. 
(30) If no, system 200 continues to automatically 
evaluate the problem or continues with normal op- 
eration, usually in the absence of any problems. 

(20) If yes (interaction required): What is the inter- 
action type: user/system (U/S) interaction (e.g., 
200, 300 or 500 with 1 000) or system/system <S/S) 
interaction (e.g., 200 with 300, 200 with 500, 300 
with 500)? 

(21) If user/system interaction, is the interaction in- 
itiated by a user or initiated by a system? 

(22) If initiated by a user, for example, user 1000 
detects a problem and starts a voluntary dialog with 
auxiliary system 300 or with system 500 at any time. 
A good opportunity for starting is to press a special- 
ized button ("PROBLEM ANALYSIS") when viewing 
an error message. 
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(23) If initiated by a sysUPPTfor example, system 
300 collects problem related data (D) by providing 
a mandatory dialog (system 300 with user 1000). 

(24) If system/system interaction, is the interaction 
initiated by a user or initiated by a system? s 

(25) If initiated by a user, for example, user 1000 
starts the operation of 200/300 (cf. description 
method 400) or the operation of 200/500. 

(26) If initiated by a system, for example, system 
200/500 starts its operation automatically. 10 

[0064] The query order can be modified: the query for 
U/S or S/S interaction (10) could follow the initializing 
queries. U/S and S/S interactions and initializations can 
be related to each other. is 
[0065] FIG. 11 illustrates a simplified scenario that 
considers primary and secondary context. 

(10) Processing problem data D to identify context 
(i.e. first context) and versions, thereby using lexi- 20 
con 331 (cf. FIG. 5). 

(20) Selecting knowledge representations R forthat 
context (or version). 

(30) Processing problem data D and knowledge 
representations R to find solutions S. 25 
(40) Querying for the existence of a solution and fin- 
ishing if solution exists. 

(50) Repeating processing to identify further con- 
text (i.e. second or higher context, or other versions) 
and querying until a solution S is identified until all 30 
contexts have been considered. 

[0066] FIG. 12 illustrates a simplified scenario that 
considers the distribution of problem collecting and so- 
lution processing for the various systems. The scenario 35 
is useful for distributed systems with main system 200, 
auxiliary system 300, and service system 500 (cf. FIGS. 
7-8). Depending on the availability of knowledge repre- 
sentations R (in auxiliary system 200 and in service sys- 
tem 500) that match to problem data D, the problem is 40 
automatically evaluated and solution S is identified by 
auxiliary system 200 or service system 500, or the prob- 
lem is manually evaluated and the solution S is found 
by a human (e.g., user or technician). Modifications to 
the scenario (semi-automatically evaluating and solv- 45 
ing) are also possible. The scenario substantially has 
the following phases: 

(10) Detecting the problem in main system 200. 

(20) Processing data D with R by auxiliary system so 

300 to identify a solution S (cf. method 400). 

(30) If processing successes to a solution S, solving 

the problem by auxiliary system 300. 

(40) If processing fails (no solution) .forwarding data 

D to service system 500 (optionally enhancing D as ss 

described above). 

(50) Processing data D with R by service system 
500 to identify a solution S (applying method 400 
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analogously). 
(60) If processing successes to a solution S, utiliz- 
ing S (i.e. solve the problem) by service system 500 
(or by auxiliary system 300 that is instructed by 
service system 500). 

(65) Optionally, supplying new R to auxiliary system 
(for finding a final solution by the auxiliary system). 
(70) If processing fails, evaluating the problem and 
finding S by a human. 

[0067] Once a solution S has been identified, it can 
be applied to actually solve the problem in a similar sce- 
nario. 

[0068] It is within the scope of the invention to super- 
impose such and other scenarios, for example, to have 
a scenario with interaction queries, with context consid- 
eration and with distribution. 

[0069] FIG. 13 illustrates simplified exemplary sce- 
narios for solving problems in main system 200. Phases 
are given in top-down direction. Phases on the left side 
belong to the first exemplary scenario with automiatically 
solving by the auxiliary system (illustrated on the left); 
phases on the right side belong to semi-automatically 
solving by forwarding enhanced data to service system 
500. Processing phases are similar and therefore illus- 
trated for both sides. 

[0070] As illustrated for the first scenario, main sys- 
tem 200 reports a problem (i.e. problem P); auxiliary 
system 300 collects the data (cf . step 41 0) to analyze 
the problem environment (i.e., operating system; ver- 
sions; tables); system 300 enhances the data by the 
problem environment; system 300 processes data (D) 
and knowledge representations (R) (problem analysis) 
to identify the solution (S). (cf. FIG. 9, (10) (30)) 
[0071] As illustrated for the second scenario, user 
1 000 initiates problem diagnosis, for example, main sys- 
tem 200 reports a problem (i.e. P). Auxiliary system 300 
processes data (D) and knowledge representations (R), 
but does not identify a solution (e.g., R insufficient, D 
unknown). The user (or a computer specialist) manually 
collects further problem related data (e.g., about oper- 
ating system); starts processing again to enhance the 
problem data (D) by environment data; re-processing by 
system 300 does however not result in a solution (S). 
Therefore, the user decides to forward the enhanced 
problem data to service system 300. Service system 
then starts to reevaluate the problem, usually with a 
more comprehensive set of knowledge representations 
(R) and solutions (S). (cf. FIG. 9, (10), (20), (21), (22), 
(10), (20), (24), (26)) 

[0072] FIGS. 9-13 concentrate on examples. Further 
scenarios can be implemented, using other yes/no que- 
ries or case distinctions. Examples are explained in the 
following. 

(a) Is there a need to manually input problem data 
D? For some cases, especially for rare problems, 
preparing comprehensive knowledge representa- 
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tions R is not possible (o^l^expensive). The user 
can enter data via dialogs or other user interface 
elements. 

(b) Does knowledge module 330 has a sufficient 
number of knowledge representations R? The 5 
number is usually sufficient if processing (step 441) 
results in solutions S. The number is usually insuf- 
ficient if processing does not result in solutions S. 

In that case, activating acquisition module 320 and 
knowledge module 330 is possible to add or modify io 
knowledge representations R. 

(c) Does knowledge module 330 need to obtain fur- 
ther knowledge representations R? This query is re- 
lated to the previous one. Representations (R) can 

be obtained from distributed systems. For example, 15 
system 300 can obtain R from system 500. This is 
convenient, for example, If system 300 operates at 
a customer site (occasional update) and system 
500 operates at the site of a system manufacturer 
(daily update). 20 

(d) Are there updates available for modules 310, 
320, 330, 340, for knowledge representations (R) 
orthe like? Again, updates can be loaded from sys- 
tem 500 to system 300. 

(e) Is human support service available in a daylight 25 
time-zone to solve a problem in a night-light time- 
zone? If service systems 500 and specialists (i.e. 
service engineer 1002) are required, then system 
200/300 could send a request to system 500 in a 
daylight time-zone. A 24-hour-service can beestab- 30 
lished with specialists working during daylight 
hours. 

(f) Is there an emergency in solving the problem or 
is there allowable waiting time? Are there 2 or more 
problems with different urgency or priority levels? 35 
Prioritizing adds value; solutions to high-profile 
problems could be searched in parallel by system 
300 and by system 500. 

(g) Did the problem cause immediate symptoms? 
Some problems show symptoms only if they have 40 
become severe (e.g., a table with data overflow). 
Auxiliary system 300 can evaluate the performance , 
of the main system to find problems before they ap- 
pear to the user. Conveniently, systems 300 or 500 
operate in the background to identify hidden prob- 45 
lems and operate in the foreground (i.e. with inter- 
action) to solve visible problems. 

(h) Having the solution identified, is there a prede- 
fined instructions sequence assigned to that solu- 
tions to automatically solve the problem? Automatic so 
(or semiautomatic) problem solving according to 
predefined instructions could follow processing. 

(I) It the problem classified in a particular error 
class? Problems and their corresponding solutions 
can be classified in great variety. Exemplary classes 55 
are: 

• Class "information", auxiliary system 300 in- 
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forms user lOOOWbut application details that 
are usually not critically to main system 200; 

• Class "operation error", user 1000 does not 
properly operate system 200 (e.g., by acci- 
dent), system 200 does not behave as speci- 
fied, such problems can be solved, for example, 
by informing user 1000 through messages. 

• Class "performance", system 200 exhibits rel- 
atively long response times; problems like this 
are often related to hardware failure or to over- 
flow of tables. 

• Class "wrong result", system 200 operates sta- 
ble, but results are calculated incorrectly or in- 
consistently, exemplary solutions are consist- 
ency correcting or debugging. 

• Class "system error", system 200 detects an 
invalid processing step; an exemplary solution 
is the identification of the system module that 
causes the error (tracking function). 

• Class "cancellation", system 200 partly or com- 
pletely stops to operate, an exemplary solution 
is to reproduce the error. 

0) Can evaluating (i.e. method 400) be repeated 
with modified parameters (i.e. iteration with different 
D, R, or S)? 

[0073] Without departing from the scope of the inven- 
tion, persons of skill in the art may add further function- 
ality, such as for context retrieval, long-text messages, 
heuristics, artificial intelligence, or exception handling. 
[0074] FIG. 14 summarizes various aspects of the 
present invention by concentrating on inference module 
340/540 (collectively x40). 

[0075] As explained above, inference module x40 
processes problem related data D with knowledge rep- 
resentations R to identify solutions S. 
[0076] Modules that make inference module x40 an 
integral part of an expert system (i.e. provide expertise 
functionality) have been explained above: modules for 
obtaining D and R (e.g., collect, acquire, store), to use 
S and - optionally - to interact with a human user. 
[0077] Briefly, inference module x40 has expertise 
functionality for evaluating problems P in main computer 
system 200 that executes an application A. Inference 
module x40 is adapted to process problem related data 
D with knowledge representations Rto identify solutions 
S. For example, inference module x40 has one of the 
following configurations: 

[0078] In a first configuration, inference module x40 
is part of auxiliary computer system 300 that uses basis 
functions of main computer system 200. Main computer 
system 200 and auxiliary computer system 300 are cli- 
ent/server systems. 

[0079] In a second configuration, inference module 
x40 is part of service system 500 that receives problem 
related data D from main computer system 200 over a 
network and that returns solutions S to main computer 
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system 200. In a first case, aWPTce system 500 returns 
solutions S that solve the problem directly. In a second 
case, service system 500 return solutions S that solve 
the problem indirectly by being further knowledge rep- 
resentations for a further inference module (e.g., mod- s 
ule340). 

[0080] In a third configuration, inference module x40 
distinguishes problem related data D and - optionally - 
knowledge representations R in context classes. 
[0081] In a fourth configuration, inference module x40 io 
is part of service system 500 that receives problem re- 
lated data D from first and second main systems 201 , 
202 of different versions over a network. Inference mod- 
ule x40 applies knowledge representations R for both 
main systems 201 , 202 and distinguishes version differ- 15 
ences of the main systems by looking up in check lexi- 
con 331 . 

[0082] The present invention can also summarized as 
follows: 

[0083] Preferably, selected context is selected by us- 20 
er 1000. 

[0084] Preferably, selected context is selected by a 
predefined rule. 

[0085] Preferably, knowledge module 330 applies a 
predefined rule to select knowledge representations R 25 
to be considered by inference module 340 according to 
the context of a current transaction in application server 
220. Preferably, context is selected from the group of: 
system and program performance, background 
processing, OCS and patches, data dictionary, printer 30 
problems, remote function calls and connectivity, R/3 re- 
porting, and security and administration. Preferably, 
main system 200 has a client/server configuration with 
database 210, application server 220 and front-end 
server 230. Preferably, computer system 200/300 is a 35 
system of an R/3 type. 

[0086] Preferably, main system 200 executes applica- 
tion A as an enterprise resource planning ERP applica- 
tion. Preferably, the EPR application is selected from the . 
group of: supply chain management, customer relation- 40 
ship management, financials, human resources, enter- 
prise portals, exchanges, technology, product lifecycle 
management, supplier relationship management, busi- 
ness intelligence, business intelligence, mobile busi- 
ness, hosted solutions, small and midsize business, in- 45 
dustry solutions. Preferably, the ERP application is de- 
fined by instructions that have common keywords, com- 
mon syntax and common semantic with environments 
selected from the group of: ABAB/4, Java 2 Platform En- 
terprise Edition J2EE, and.NET framework. Preferably, so 
auxiliary system 300 uses client/server configuration 
21 0, 220, 230 of main system 200; the modules of aux- 
iliary system 300 are distributed such that service mod- 
ule 310, acquisition module 320, knowledge module 
330, and inference module 340 are arranged in parallel ss 
to application server 220 and to database 210. Prefer- 
ably, front-end server 230 operates as user-interface for 
the main system 200 and for auxiliary system 300. Pref- 
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erably, computer systerrTlTO/300 uses Internet commu- 
nication between application server 220 and front-end 
server 230. 

[0087] Preferably, service module 310 makes basis 
service functions of main system 200 available for aux- 
iliary system 300. Preferably, the basis service functions 
are selected from the group of ABAP/4 workbench, ad- 
ministration, authorizations, batch input, data dictionary, 
dialog control, framework, graphical user interface, ap- 
plication program interface, and job. Preferably, service 
module 310 cooperates with main system 200 to obtain 
problem related data D for auxiliary system 300. Prefer- 
ably, service module 310 cooperates with database 21 0 
to test the existence of objects, wherein problem related 
data D comprises information about existence and non- 
existence of the objects. Preferably, service module 310 
cooperates with database 210 to obtain the content of 
a table entry as problem related data D. Preferably, serv- 
ice module 310 records events in the operating system 
of main system 200 by writing to database 210. 
[0088] Preferably, service module 31 0 records prob- 
lem related data D obtained from data consistency 
check operations of main system 200. Preferably, serv- 
ice module 31 0 instructs front-end server 230 to provide 
dialogs with user 1000. 

[0089] Preferably, service module 310 provides re- 
mote function call RFC connections with service system 
500. Preferably, service module 310 monitors applica- 
tion server 220 and database 210 according to instruc- 
tions from inference module 340. 
[0090] Preferably, acquisition module 320 also modi- 
fies knowledge representations R. Preferably, acquisi- 
tion module 320 interacts with knowledge engineer 
1001 . Preferably, acquisition module 320 interacts with 
knowledge engineer 1000 through tree 322 on a graph- 
ical user interface. Preferably, acquisition module 320 
uses tree 322 to represent knowledge representations 
R as a semantic net. 

[0091] Preferably, knowledge module 330 is adapted 
to receive regular updates of the knowledge represen- 
tations R from service system 500. Preferably, knowl- 
edge module 330 stores the knowledge representations 
R in database 210 with entries for specific problem P 
symptoms and corresponding solutions S. Preferably, 
knowledge module 330 stores knowledge representa- 
tions R in the database 210 with entries for predefined 
solution identification rules. Preferably, the solution 
identification rules are provided in a meta language. 
Preferably, the meta-language is derived from ABAP/4. 
[0092] Preferably, knowledge module 330 generates 
a structured set of problem solving strategies. Prefera- 
bly, knowledge module 330 generates solution identifi- 
cation rules with computer instructions to automatically 
solve the problem. Preferably, computer system 
200/300 is adapted to use the solution identification 
rules for automatically solving the problem. 
[0093] Preferably, sets of semantically related solu- 
tion identification rules are grouped together. Preferably, 
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knowledge module 330 storaWmowledge representa- 
tions R in a plurality of tables in database 210. Prefera- 
bly, the tables are provided prior to activating auxiliary 
system 300. 

[0094] Preferably, inference module 340 identifies the s 
solutions S from sets of predefined advices. Preferably, 
inference module 340 identifies the solutions S from 
sets of predefined advices that are advices of the appli- 
cation A. Preferably, inference module 340 identifies the 
solutions by applying the knowledge representations R. 10 
Preferably, inference module 340 applies the knowl- 
edge representations R in a predefined order. Prefera- 
bly, the predefined order is a sequential order. Prefera- 
bly, the predefined order is a hierarchical order. Prefer- 
ably, the predefined order is a dynamically adaptive or- 15 
der. Preferably, inference module 340 communicates 
questions to user 1000 via front-end server 230. Prefer- 
ably, inference module 340 communicates questions 
that are standard questions. Preferably, inference mod- 
ule 340 consecutively numbers the questions. Prefera- 20 
bly, inference module 340 composes the questions from 
predefined passages that are provided by the applica- 
tion server 220. Preferably, inference module 340 ana- 
lyzes responses that the user enters in natural lan- 
guage. Preferably, auxiliary system 300 conditionally 25 
forwards problem P data to service system 500. 
[0095] Preferably, auxiliary system 300 forwards the 
problem P data to service system 500 with preliminary 
analysis data based on processing with knowledge rep- 
resentations R in auxiliary system 200. Preferably, aux- 30 
iliary system 300 forwards problem P data for further 
analysis by a human technician. 
[0096] Preferably, auxiliary system 300 forwards 
problem data P and preliminary solutions S to service 
system 500 in a format that allows evaluation in the serv- 35 
ice system 500. Preferably, main system 201 is physi- 
cally implemented by a first computer, service system 
500 is implemented by a second computer and further 
main system 202 is implemented by a third computer. 
Preferably, main system 201 is adapted to be operated 40 
by a first customer, service system 500 is implemented 
by an expertise service provider ESP, and the at least 
one further main system 201 is adapted to be operated 
by a second customer. 

[0097] Preferably, main system 200 and the further 45 
main system 201 are systems of the same type, but 
have different release versions. Preferabfy, some of the 
computers are located at physically different locations. 
Preferably, computer system 200/300 has a further 
module to identify a predefined instructions sequence, so 
wherein the instruction sequence is assigned to solution 
S that is identified by inference module 340. 
[0098] FIG. 15 illustrates a simplified block diagram 
of exemplary computer system 999 in general for that 
the present invention can be implemented. System 999 55 
has a plurality of computers 900, 901, 902 (or even 
more). Computer 900 can communicate with computers 
901 and 902 over network 990. Computer 900 has proc- 
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essor 910, memory 920^B§ 930, and, optionally, input 
device 940 and output device 950 {I/O devices, user in- 
terface 960). As illustrated, the invention is implemented 
by computer program product 100 (CPP), carrier 970 
and signal 980. 

[0099] In respect to computer 900, computer 901/902 
is sometimes referred to as "remote computer", compu- 
ter 901/902 is, for example, a server, a peer device or 
other common network node, and typically has many or 
all of the elements described relative to computer 900. 
[0100] Computer 900 Is, for example, a conventional 
personal computer (PC), a desktop device or a hand- 
held device, a multiprocessor computer, a pen compu- 
ter, a microprocessor-based or programmable consum- 
er electronics device, a minicomputer, a mainframe 
computer, a personal mobile computing device, a mo- 
bile phone, a portable or stationary personal computer, 
a palmtop computer or the like. 

[0101] Processor 910 is, for example, a central 
processing unit (CPU), a micro-controller unit (MCU), 
digital signal processor (DSP), or the like. 
[0102] Memory 920 is elements that temporarily or 
permanently store data and instructions. Although 
memory 920 is illustrated as part of computer 900, mem- 
ory can also be implemented in network 990j in comput- 
ers 901/902 and in processor 91 0 itself (e.g., cache, reg- 
ister), or elsewhere. Memory 920 can be a read only 
memory (ROM), a random access memory (RAM), or a 
memory with other access options. Memory 920 is phys- 
ically implemented by computer-readable media, for ex- 
ample: (a) magnetic media, like a hard disk, a floppy 
disk, or other magnetic disk, a tape, a cassette tape; (b) 
optical media, like optical disk (CD-ROM, digital versa- 
tile disk - DVD); (c) semiconductor media, like DRAM, 
SRAM, EPROM, EE PROM, memory stick. 
[01 03] Optionally, memory 920 is distributed. Portions 
of memory 920 can be removable or non- removable. 
For reading from media and for writing in media, com- 
puter 900 uses well-known devices, for example, disk 
drives, or tape drives. 

[0104] Memory 920 stores modules such as, for ex- 
ample, a basic input output system (BIOS), an operating 
system (OS), a program library, a compiler, an interpret- 
er, and a text- processing tool. Modules are commer- 
cially available and can be installed on computer 900. 
For simplicity, these modules are not illustrated. 
[0105] CPP 100 has program instructions and - op- 
tionally - data that cause processor 910 to execute 
method steps of the present invention. In other words, 
CPP 1 00 can control the operation of computer 900 and 
its interaction in network system 999 so that is operates 
to perform in accordance with the invention. For exam- 
ple and without the intention to be limiting, CPP 1 00 can 
be available as source code in any programming lan- 
guage, and as object code ("binary code") in a compiled 
form. 

[0106] Although CPP 1 00 is illustrated as being stored 
in memory 920, CPP 100 can be located elsewhere. 
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CPP 100 can also be emboS^Fh carrier 970. 
[0107] Carrier 970 is illustrated outsidecomputer 900. 
For communicating CPP 100 to computer 900, carrier 
970 is conveniently inserted into input device 940. Car- 
rier 970 is implemented as any computer readable me- 
dium, such as a medium largely explained above (cf. 
memory 920). Generally, carrier 970 is an article of man- 
ufacture having a computer readable medium with com- 
puter readable program code to cause the computer to 
perform methods of the present invention. Further, sig- 
nal 980 can also embody computer program product 
100. 

[0108] Having described CPP 100, carrier 970, and 
signal 980 in connection with computer 900 is conven- 
ient. Optionally, further carriers and further signals em- 
body computer program products (CPP) to be executed 
by further processors in computers 901 and 902. 
[0109] Input device 940 provides data and instruc- 
tions for processing by computer 900. Device 940 can 
be a keyboard, a pointing device (e.g., mouse, trackball, 
cursor direction keys), microphone, joystick, game pad, 
scanner, or disc drive. Although the examples are de- 
vices with human interaction, device 940 can also be a 
device without human interaction, for example, a wire- 
less receiver (e.g., with satellite dish or terrestrial anten- 
na), a sensor (e.g., a thermometer), a counter (e.g., a 
goods counter in a factory). Input device 940 can serve 
to read carrier 970. 

[0110] Output device 950 presents instructions and 
data that have been processed. For example, this can 
be a monitor or a display, (cathode ray tube (CRT), flat 
panel display, liquid crystal display (LCD), speaker, 
printer, plotter, vibration alert device. Output device 950 
can communicate with the user, but it can also commu- 
nicate with further computers. 

[01 1 1] Input device 940 and output device 950 can be 
combined to a single device. Any device 940 and 950 
can be provided optional. 

[0112] Bus 930 and network 990 provide logical and 
physical connections by conveying instruction and data 
signals. While connections inside computer 900 are 
conveniently referred to as "bus 930", connections be- 
tween computers 900-902 are referred to as "network 
990". Optionally, network 990 includes gateways which 
are computers that specialize in data transmission and 
protocol conversion. 

[01 1 3] Devices 940 and 950 are coupled to computer 
900 by bus 930 (as illustrated) or by network 990 (op- 
tional). While the signals inside computer 900 are mostly 
electrical signals, the signals in network are electrical, 
electromagnetic, optical or wireless (radio) signals. 
[0114] Networks are commonplace in offices, enter- 
prise-wide computer networks, intranets and the Inter- 
net (e.g., world wide web). Network 990 can be a wired 
or a wireless network. To name a few network imple- 
mentations, network 990 can be, for example, a local 
area network (LAN), a wide area network (WAN), a pub- 
lic switched telephone network (PSTN); a Integrated 



orl^oD 



Services Digital NetworWSbN), an infra-red (IR) link, 
a radio link, like Universal Mobile Telecommunications 
System (UMTS), Global System for Mobile Communi- 
cation (GSM), Code Division Multiple Access (CDMA), 
or satellite link. 

[0115] A variety of transmission protocols, data for- 
mats and conventions is known, for example, as trans- 
mission control protocol/internet protocol (TCP/IP), hy- 
pertext transfer protocol (HTTP), secure HTTP, wireless 
application protocol (WAP), unique resource locator 
(URL), a unique resource identifier (URI), hypertext 
markup language (HTML), extensible markup language 
(XML), extensible hypertext markup language 
(XHTML), wireless markup language (WML), Standard 
Generalized Markup Language (SGML). 
[0116] Interfaces coupled between the elements are 
also well known in the art. For simplicity, Interfaces are 
not illustrated. An interface can be, for example, a serial 
port interface, a parallel port interface, a game port, a 
universal serial bus (USB) interface, an internal or ex- 
ternal modem, a video adapter, or a sound cardi 
[01 17] Computer and program are closely related. As 
used hereinafter, phrases, such as "the computer pro- 
vides" and "the program provides", are convenient ab- 
breviation to express actions by a computer that is con- 
trolled by a program. 
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10. 

1. Computer system (200/300) with a main system 10 
(200) to execute an application (A) in cooperation 
with a human user (1000), the computer system 
with an auxiliary system (300) to evaluate problems 

(P) in the main system (200) w|th a service module 
(310) to collect problem related data (D) from the 15 11. 
main system (200), an acquisition module (320) to 
acquire knowledge representations (R), a knowl- 
edge module (330) to store the knowledge repre- 
sentations (R), an inference module (340) to proc- 
ess problem related data (D) with knowledge rep- 20 12. 
resentations (R) to identify solutions (S), the infer- 
ence module (340) also to forward the solutions (S) 
through the service module (310) to the main sys- 
tem (200), the computer system (200/300) charac- 
terized in that the auxiliary system (200) distin- 25 
guishes context of the problems (P) and distinguish- 
es versions of the main system (200). 

2. Computer system (200/300) of claim 1 , wherein the 
auxiliary system (200) also distinguishes context 30 
and versions relating to the application (A). 

3. Computer system (200/300) of claim 2, wherein the 
auxiliary system (200) distinguishes context and 
versions by using a check lexicon (331) in the 35 
knowledge module (330). 

4. Computer system (200/300) of claim 3, wherein the 
check lexicon (331) lists details for the knowledge 
representations (R), wherein the details depend on 40 
a version of the main system. 

5. Computer system (200/300) of claim 3, wherein the 
check lexicon (331) lists details for the knowledge 
representations (R), wherein the details depend on 45 
a version of the application (A). 



Computer system (200/300) of claim 1 , wherein the 
knowledge module (330) distinguishes contexts 
that are predefined sets of knowledge representa- 
tions (R). 

Computer system (200/300) of claim 1 , wherein the 
knowledge module (330) distinguishes context with 
primary context and secondary context, wherein the 
secondary context is referenced from the first con- 
text. 

Computer system (200/300) of claim 1 , wherein the 
knowledge module (330) makes knowledge repre- 
sentations (R) selectively available or non-available 
according to a selected context. 

Inference module (x40) with expertise functionality 
for evaluating problems (P) in a main computer sys- 
tem (200) that executes an application (A), wherein 
the inference module (x40) is adapted to process 
problem related data (D) with knowledge represen- 
tations (R) to identify solutions (S), the inference 
module (x40) characterized in that the inference 
module (x40) distinguishes problem related data 
(D) in context classes. 



6. Computer system (200/300) of claim 3, wherein the 
check lexicon (331) lists details for the knowledge 
representations (R), wherein the details depend on so 
the context of the problem (P). 

7. Computer system (200/300) of claim 3, wherein the 
check lexicon (331) lists details for the knowledge 
representations that depend on a version of the 55 
main system (200). 

8. Computer system (200/300) of claim 3, wherein the 



13 



EP 1 416 439 A1 



200- 
MAIN 

300- 
AUX 



1000 



USER 



(pV 


-{IT 


) 0, 


310 SERVICE 




COLLECT / 


340 INFERENCE 




^\*y^ FORWARD 


330 KNOWLEDGE 




> STORE 


320 ACQUISITION 




■f 

x ACQUIRE 




FIG. 1 



14 



EP 1 416 439 A1 



230 



220 



210 



FRONT END 







APPLICATION 






DATABASE 


V s 


, ' 



310 

/ 


SERVICE 


INFERENCE 




KNOWLEDGE 




ACQU 






300 



200 

COMPUTER SYSTEM 200/300 



340 



330 



320 



FIG. 2 



15 



EP 1 416 439 A1 



310 



230 



220 



210 



FRONT- END SERVER 


SERVICE MODULE 


DIALOG 


BASIS FUNCTIONS 


APPLICATION SERVER 




MUNIIUK 




CONSISTENCY CHECK 




DATABASE 




DOES OBJECT EXIST? 




TABLE ENTRY 




WRITE OPERATION 





200 



SERVICE MODULE 310 



FIG. 3 



16 



EP 1 416 439 A1 



PATCH TYPE 




, _^ . TREE 

CD ] (OSS) ( INTERNET 322 



INSERT 
OBJECT 




^—1001 



ACQUISITION MODULE 320 



FIG. 4 



17 



• 



EP 1 416 439 A1 



331 LEXICON 



VERSION 

1.0 
2.0 


Pa R 







FIRST CONTEXT SECOND CONTEXT 



UPDATES 



KNOWLEDGE MODULE 330 



FIG. 5 



18 



EP 1 416 439 A1 



SOLUTION IDENTIFIER 
SET OF ADVICES 
R TO APPLY 
R1.R2.R3 

R1,R21,R21,R31,R32 
IF THEN 

Q1, 02, Q3 RESERVOIR 
LANGUAGE ANALYZER 



INFERENCE MODULE 340 

FIG. 6 



19 



* 



EP 1 416 439 A1 



200/300 



MAIN/AUX 



NETWORK 



500 



SERVICE 



510 
520 
530 
540 



FIRST DISTRIBUTED SYSTEM LANDSCAPE 



FIG. 7 



20 



EP 1 416 439 A1 



MAIN 




SERVICE 




MAIN 






t 

201 


i 

500 


i 

202 



CUSTOMER 1 EXPERTISE CUSTOMER 2 

SERVICE 
PROVIDER 



SECOND DISTRIBUTED SYSTEM LANDSCAPE 

FIG. 8 



21 



• 



EP 1 416 439 A1 



410 



420' 



430- 



441 



442 



collecting problem related data (D) 



acquiring knowledge representations (R) 



storing knowledge representations (R) 



processing data (D) and representations (R) to 
identify solutions (S) 



forwarding solutions (S) 



400 



FIG. 9 



22 



EP 1 416 439 A1 



INTERACTION 
REQUIRED ? 



YES 




NO 




SYSTEM / SYSTEM 



INITIATED 



u 






~22 


DIALOG 


VOLUNTARY 





24 








-—25 


START BY 


USER 





30 

jL 



NORMAL 
OPERATION 



AUTOMATIC 
EVALUATION 



INITIATED BY ? 



DIALOG 
MANDATORY 





S 




~26 


START 




AUTOMATICALLY 



FIG. 10 



23 



EP1 416 439 A1 



START ) 



PROCESS D TO 
IDENTIFY CONTEXT 



SELECT R FOR 
CONTEXT 



PROCESS D. R 




YES 



END 



FIG. 11 



24 



EP1 416 439 A1 



10' 



DETECTING PROBLEM 



CO- 



PROCESSING BY AUX SYSTEM 



SUCCESS. 



^FAILURE 



IDENTIFY S 
BY AUX 
SYSTEM 



FORWARDING 
TO SERVICE 
SYSTEM 



PROCESSING 



40 



SUCCESS. 



— 50 
FAILURE 



60- 



IDENTIFY S BY 
SERVICE SYSTEM 



SOLVING BY 
HUMAN 



SUPPLY NEW R 
TO AUX SYSTEM 
FOR FURTHER 
PROCESSING 



7 

70 



12 



25 



EP 1 416 439 A1 




CO 

8 «■ 

Z CO 

i g 

S3 g 



CM 



DC 
UJ 

CO 



CO 



CO 
LU 

g £ 

<=> Q 



H- CO 

CO UJ 

>- o 

CO o 

=3 

< m 



LU S 



LU 

a. 
x 



Of CD 
LU O 
CO C£ 



CO 

o 

QL 



CM 



52 

CO 



CO 

I— 

o 

LUI 



o 
o 

CO 



CO 

So 

X 



"J CO 

s I 



LU 



CO 

I— 
o 

UJ 

»- 

UJ 



CO z 

co 5 

X 5> 



CO 

2 



00 

o 

DC 

or 

a 
o 

co 
co 

IAJ 

o 
o 



CO 

o 



8 



o s 

I- UJ 

5 co 

OC LU 

p 

O LU 

LL. CO 



CO 

o 



26 



EP 1 416 439 A1 



CD 




© 



200 













X40 




VERSIONS 
331 



201, 202 



FIG. 14 



27 




28 



EP 1 416 439 A1 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



EP 02 02 4530 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate. 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION <lntC».7) 



US 6 295 525 Bl (GRAHAM JAMEY ET AL) 
25 September 2001 (2001-09-25) 

* abstract * 

* column 1, line 42 - line 51 * 

* column 2, line 9 - line 46 * 

* column 5, line 52 - line 60 * 

* column 13, line 9 - line 26 * 

SHUTT T S ET AL: "COPRA: Computer 
Operations Problem Resolution Assistant" , 
PROCEEDINGS OF THE CONFERENCE ON 
ARTIFICIAL INTELLIGENCE FOR APPLICATIONS. 
ORLANDO, MAR. 1 - 5, 1993, LOS ALAMITOS, 
IEEE C0MP. SOC. PRESS, US, VOL. CONF. 9, 
PAGE(S) 107-113 XP010125568 
ISBN: 0-8186-3840-0 

* abstract * 

* page 108, right-hand column, line 47 - 
page 109, left-hand column, line 18 * 



1 

12 



1,12 



G06N5/02 



TECHNICAL FIELDS 
SEARCHED (lnLCI.7) 



G06N 

G06F 



The present search report has been drawn up for all claims 



THE HAGUE 



3 June 2003 



Klngma, Y 



CATEGORY OF CfTED DOCUMENTS 

X : particularly retevant if taken alone 

Y : particularly relevant it combined with another 

document of the same category 
A : technological background 
O : non-wrlnen disclosure 
P: 



T : theory or principle underlying the Invention 
E : earlier patent document but published on, or 

after the fifing date 
D : document cBed fei the application 
L : document cited for other reasons 



A : member of the same paieni family, corresponding 



29 



EP1 416 439 A1 




ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 02 02 4530 



This annex Dste the patent family members relating to the patent documents cited In the above-mentioned European search report 
The members are as contained in the European Patent Office EDP file on * 
The European Patent Office Is In no way liable for these particulars which are merely given for the purpose of information. 

03-06-2003 



Patent document 
cited in search report 



Publication 



Patent tamily 
members) 



Publication 
date 



US 6295525 Bl 25-09-2001 US 6049792 A 11-04-2000 

US 6041182 A 21-03-2000 

US 5546502 A 13-08-1996 

US 2001051938 Al 13-12-2001 

GB 2329989 A ,B 07-04-1999 

HK 1019797 Al 13-07-2001 

JP 11167452 A 22-06-1999 

DE 616288 Tl 30-11-1995 

EP 0616288 A2 21-09-1994 

JP 6274300 A 30-09-1994 



S 



in For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



30 



